1. Technical Field
The present invention relates in general to the field of computers, and, in particular, to the field of computer software. Still more particularly, the present invention relates to an improved method and system for managing, including locating, object classes in an object oriented programming environment.
2. Description of the Related Art
Object-oriented programming (OOP) is a type of computer programming used in the development of operating software as well as application software for a computer system. Contrary to traditional procedural programming techniques, OOP comprises and uses pre-engineered “methods” and “variables” that make up an “object” of computer code. When an object is populated with specific data, the object is called an “instance.”
An instance is created by a “class,” which is a software template from which an object is instantiated. The class defines both the methods (software algorithms) used by the object as well as the format of variables (e.g. integers, strings, pointers to other objects, etc.) used by the methods.
Instances can be persisted by many means. In many cases instances are mapped to relational database tables with each instance being a row in the table. No matter what means is used to persist the instance, some way of working with the persisted instances is needed. In the case of a relational database, some way of locating the newly created instance into the database is needed as well as some means of locating instances within the database. This can be done using another object that acts as an intermediary called the “home.”
FIG. 1 depicts graphically the relationship between classes, methods, variables and instances. Class 10 contains the software template that defines methods 12 and variables 14 to be included in a particular object. Methods 12 and variables 14 are defined only once in the definition of the class. Class 10 defines how instances 16 (depicted as instances 16a–16c) are built, with each instance 16 being populated with data values that represent that instance 16's particular contents and location.
The concept of both methods and variable being contained inside an object is called “encapsulation.” Part of the concept of encapsulation is that an object has a predictable way of communicating with other objects by sending “messages” back and forth through a well defined software interface. A message from a sending object contains the name of the intended receiving object plus the name of a method contained in the receiving object that the sending object wants to be performed. If the method to be performed requires any additional information in order to know precisely what to do, the message includes that information as a collection of data elements called “parameters.”
OOP also incorporates the feature of “inheritance”, which is a mechanism whereby one class can be defined as a special case of a more general class, automatically including the method and data (variable) definitions of the general class. These special cases of a class are known as “subclasses” of that class; the more general class, in turn, is known as the “superclass” of its special cases. In addition to the methods and data variables they inherit, subclasses may define their own methods and variables and may override any of the inherited characteristics.
Inheritance allows reuse of the software that is using a more general class. Writing the software to use the more general class allows subclasses to be substituted at run time. Thus the using software is written to use the appropriate message and the chosen subclass provides the particular implementation (method) that handles the message. This technique is often used when writing reusable software. The use of inheritance allows the reusable software to be easily customized by creating new subclasses and using them polymorphically in place of the superclass.
OOP is implemented in two ways: client-side operations and server-side operations. Most of the earlier OOP operations were client-side, including those performed using Java™, a platform independent object-oriented programming language developed by Sun Microsystems, Inc. (Sun). Examples of client-side operations include servlets 20 and applets 22 as illustrated in FIG. 2. Applets 22 are portable Java programs that can be downloaded on the fly and can execute in an untrusted environment. Typically, applets 22 are deployed in a Web page sent from Web server 18 to client computer 24, whose browser 26 contains a browser applet viewer to run applet 22. Applets 22 typically display a user interface on client computer 24. Servlets 20 are applets that run on Web server 18 in Web server's servlet engine. Servlets 20 are networked components that can be used to extend the functionality of Web server 18. Servlets 20 are request/response oriented, in that they take requests from browser 26 and issue a response back to client computer 24. Servlets 20 are often used for performing Web tasks such as rendering a HyperText Markup Language (HTML) interface to an e-commerce catalog.
Server-side operations are those that operate typically in an application server 28, as depicted in FIG. 3. Applications are sent from application server 28 to client computer 24 typically upon a request from client computer 24. Server-side operations are useful in executing complex algorithms or performing high-volume business transactions. Application server 28 provides a highly available, fault-tolerant, transactional and multiuser secure environment. While applets 22 and servlets 20 may be deployed in server-side operations, Enterprise JAVABeans objects 30 are primarily used for server-side operations.
Java 2 Platform, Enterprise Edition™ (J2EE), developed by Sun, is a robust suite of middleware services for developing server-side applications. An integral part of J2EE are Enterprise JAVABEANS™ (EJB), which define a server-side architecture that enables and simplifies the process of building enterprise-class (appropriate for a large enterprise, i.e. business organization) enterprise objects 30. EJB allows the writing of scalable, reliable and secure applications in a platform-independent environment similar to that found when using Java. Thus EJB components can be provided from a variety of vendors, and simply “plugged in” to a network system.
EJB incorporates the use of server-side software components called enterprise beans, which can be deployed in a distributed multi-tier environment illustrated in FIG. 4. In a multi-tier environment, client computer 24 has limited resident application software, and thus is called a “thin” client. The majority of the software applications and data are distributed across multiple servers 32, each of which may be an embodiment of application server 28, Web server 18, or any other data or application server. EJB defines two different kinds of enterprise beans: session beans and entity beans.
Session beans represent work being performed for client code that is calling it. Session beans are business process objects that implement business logic, business rules, and workflow. Examples of session beans are price quoting, order entry, inventory methods, etc. They are reusable components that contain logic for business processes, and typically are instantiated only for the length of time the client is using the session bean. When the client disconnects from the application server, terminating the session, the session bean is typically destroyed (although not its class).
Entity beans represent persistent data, such as bank account records, order histories, personnel records, etc. In many applications, entity beans represent real data objects, such as customers, products or employees.
EJB uses homes to access the database associated with an Entity. Each Entity has a home. A home is associated with a particular table as part of ‘deployment’. This association is done via a look-up table, such as a Java Naming Directory Interface (JNDI) table 25, as depicted in FIG. 5. Client code typically will always look-up the home to use in JNDI. This allows the deployer to choose different tables or servers on which to persist the tables.
As described above, a class, as well as its enterprise entity bean instances, can inherit methods and variables from a parent or “superclass.” For example, consider the entity object classes for Money class 48 and EuroMoney class 50, depicted in FIG. 5. MoneyHome 46 is an intermediary object for locating the Money class 48 that is to be created. For example, MoneyHome 46 may work with a table, and Money class 48 may be define as a mapping into a row layout (as part of deployment), including the size and format of the row. Thus, Money class 48 may define a row having a name field for a currency name (string format) and a currency field for U.S. Dollars (formatted to 0.01 decimals). For example, the row defined by Money class 48 for U.S. Currency, where the currency is described in 0.01 Decimals and the name of the currency (U.S. Dollars) is a string of characters, would be:
.01 DecimalStringWhen populated by specific names and figures, Money class 48 is said to instantiate an instance, typically called “money.”
Subsequently, a programmer may wish to have a new class which has different behavior or attributes. The EuroMoney subclass 50 inherits the methods and attributes from Money class 48 and changes the behavior of the “convert” method from Money class 48. The “convert” method on Money class 48 looks up the exchange rate and uses the maximum precision allowed by decimal. The “convert” method on EuroMoney subclass 50 conforms to the Euro requirements that specific steps with specific precision be used when converting to Euro from a currency moving to the Euro, such as German marks. EuroMoney subclass 50 could also add an additional currency and decimal to allow it to hold the original currency and value as well as the Euro currency and value. By changing the “convert” method, subclass EuroMoney subclass 50 is created. New row layouts for EuroMoney subclass 50 are defined during deployment and can either be mapped to the same table as the Money class 48 or to its own table. When the new object EuroMoney subclass 50 is created, EuroMoneyHome 52 is also created, either by the programmer or automatically by the environmental software. If Money class 48 and EuroMoney subclass 50 are deployed to the same table (called deployed with inheritance), then both Money class 48 and EuroMoney subclass 50 are visible from the MoneyHome 46. No matter how they are deployed, only the EuroMoney subclass 50 is visible from the EuroMoneyHome 52.
While the EuroMoney subclass 50 has inheritance from the Money class 48, there is no inheritance between MoneyHome 46 and EuroMoneyHome 52. That is, EJB and the JAVA specifications do not permit MoneyHome 46 having a method signature                Money create (Decimal)to have a subclass EuroMoneyHome 52 with a method signature        EuroMoney create (Decimal).That is, two methods may not only differ in their return value. Also, the EJB specification of home classes requires the create method to always return the type of the entity they are the home for. For example, the MoneyHome 46 “create” method must return Money class 48 and EuroMoneyHome 52's “create” method must return EuroMoney subclass 50. The homes cannot return a superclass of the entity they are associated with.        
Code that uses the MoneyHome 46 to create and locate instances of Money class 48 cannot be easily changed to create and locate EuroMoney subclass 50 instances instead. The client code 24 using Money class 48 is written to use the signatures on the MoneyHome 46. EuroMoneyHome 52 cannot be used without modifying the client code 24. The look-up of which home was assigned at deployment doesn't solve the problem because the assigned home must adhere to the correct home interface and as described above EuroMoneyHome 52 cannot be substituted (used polymorphically) for MoneyHome 46 because they cannot have an inheritance relationship.
The benefits of the polymorphic behavior of Money class 46 and EuroMoney subclass 50 cannot be taken advantage of when reusing the client code. In order to use client code, the client code must be modified. This limits the ability to reuse existing code and, when the source code for client code is not available, may make it impossible.
Therefore, there is a need for a method to write client code such that the client code can be programmatically switched to create and locate subclasses. Thus the client code should be able to locate and use the correct home for the subclass or its parent class as appropriate.